
rendering needs a snapshot
atomic updates don't really help. it needs a single state, everything at one moment
must see: bounding boxes. some internal data: floats, names
	(it doesn't make sense for this data to be atomic: they can't update independently)


input has two compnents: audio, and UI
UI depends on the rendering. might as well queue it up and store timestamps
however, that means things which depend on the UI and have other visible side effects get delayed.
	so if music depends on clicking buttons, you're in trouble.


so we have two pathways. one sends to audio. another sends to rendering.
audio comes first: lock is usually not in contention. then sends to render, where lock is in contention usually. (rendering and input processing cannot happen simultaneously)

recompilation will be a problem. a signal from the rendering thread to the audio thread.
whereas all the other messages are from the input thread to the audio thread
otherwise, audio events should bypass rendering.

recompilation could simply shut down the thread and start it up again.
that's honestly quite a fair solution. join the thread to avoid multithreading issues.
can also pre-emptively signal the shutdown at the beginning of compilation, and wait for the shutdown to complete after compilation finishes.


https://www.ee.columbia.edu/~mim/meap/paMat/portaudio_v18_1/docs/pa_impl_startstop.html



while the input thread is busy, it doesn't receive new mouse positions.
turns out it's very important that it process events instantly. it doesn't retrieve all cursor positions - just the most recent one.
"When mouse messages are posted faster than a thread can process them, the system discards all but the most recent mouse message." https://docs.microsoft.com/en-us/windows/win32/inputdev/about-mouse-input

input needs to pass any heavyweight operations to another thread.
render thread should do things that affect renderable state
side parallel thread is for things that affect other things (like databases), and shouldn't wait for rendering.